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METHOD AND SYSTEM FOR LINKING 
CERTIFICATES TO SIGNED FILES 

Copyright notice 

A portion of the disclosure of this patent docuitient 
contains material which is siabject to copyright protection. 
The copyright owner has no objection to the facsimile repro- 
duction by anyone of the patent disclosure, as it appears in 
the National Patent and Trademark Office patent file or 
records, but otherwise reserves all copyright rights 
whatsoever. 

Field o£ the Invention 

The present invention relates generally to network 
computing security and more specifically to a method and 
systems for linking a digital certificate to a digitally 
■■signad. .fi-le . that, can be .acaesjsjed. thraugh-a netwoiik ,^OL-.a,s...ta 
provide ■ information relative to the signer identity and the 
validity of the signature that can be used before opening 
the file. ■ 

Background o£ the Invention 

To improve data transmission security over computer 
networks and to prevent digital forgery, a digital signature 
is commonly used to authenticate a file i.e., to check file 
integrity and to authenticate signer. Such digital signature 
allows, for example, to control the source of a received 
file, and to verify the file integrity. A digital signature 
asserts that the user corresponding to the digital signature 
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wrote or otherwise" agreed with the contents of an electronic 
. document or other infoi:mation object ; .to which the digital 
signature is appended. As with written signatures, digital 
signatures provide authentication of the signer's identity, 
5 acceptance of the terms stated in the sighed document ^ proof 
of the integrity of the document's contents, and non 
repudiation (in other words ^ the signer cannot deny what 
he/she has signed) _ Digital signatures are generally based 
upon public key algorithms wherein security is provided 
10 through keys independently of the used algorithm, which may 
be freely published or analyzed. 

A digital certificate can be considered as an attach- 
ment to a signed document, to link the identity of the 
signer of the document to his/her public key, A digital 

15 certificate provides a cryptographic public key that allows 
another party to encrypt information for the certificate's 
owner. A digital certificate also allows to verify that a 
user sending a document is who he/she claims to he, and to 
provide the receiver with the means to encode a reply. A 

20 certificate therefore securely identifies the owner of the 
public key pair^ which is lased to provide authentication, 
authorization, encryption, a,nd non- repudiation services. A 
digital certificate contains the signer ^s public key and 
bears' the digital signature of a Certification Authority 

25 (CA) - The most widely used standard for digital certificates 
is X.509, Version 3, "The Directory-Authentication Framework 
1988'V promulgated by the International Telecommunications 
Union (ITIJ) , which defines the following structure for 
public-key certificates: 

30 - version field (identifyirkg the certificate format) 

- Serial Number (unique within the CA) 
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- Signature Algorithm (identifying the issuer's hash and 
digital signature algorithms used, to sign the certificate) 

- Issuer Name (the name of the CA) 

- Period of Validity (a pair of »^Not Before", and "Not 
5 After" Dates) 

- Subject IsTame (the name of the user to whom the certifi- 
cate is issued) 

- Subject's Public Key field (including Algorithm name and 
the Public Key of the subject) 

10 - Extensions 

- Signature of CA 

A certification authority is the third party that 
everyone trusts whose responsibility is to issue digital 
certificates providing the link between the signer and the 

15 signer's public key. A certification authority (CA) also 
keeps records about the transactions that occur using 
certificates it has issued. An individual wishing to sign a 
document applies for a digital certificate from a Certifica^ 
tion Authority- The digital certificate is digitally signed 

20 by the issuing Certification Authiority that ensures both 
content and source integrity. The CA makes its own public 
key readily availa±>le through, for example,- print publicity 
or on the Internet. The act of digitally signing makes the 
certificates substantially tamperproof, and therefore 

25 further protection is not needed. The strength of protection 
equates directly to the strength of the algorithm and key 
size used in creating the issuer's digital signature {hash 
and digital signature algorithms) . 
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The signature verification process ctiecks the digital 
signature 'appended or attached to a document using .the 
public verification key extracted from the digital certifi- 
cate/ issued by the CA, that must be also appended to or 
5 referenced in the document- Using the public key of the 
signer^ the signature verification process recovers from the 
digital signature^ the hash value ^ computed by the signer 
in the file that was signed using the private key of the 
signer during the authentication process. To verify that the 

10 file is authentic,, the receiver computes also the hash value 
of the document, and then compares the deciphered hash value 
with the real hash value^ computed from the file. If both 
hash values are identical, the file is accepted as 
authentic, otherwise, the file is rejected as being 

15 corrupted or fake- 
Once the digital signature of a file Inas been computed' 
and the file has been signed with the digi-tal signature for 
verification purposes, a digital certificate must be associ- 
ated with the signed file to make possible the verification 

20 of the digital signature by the recipient. 

Generally, a digital certificate used for authenticat- 
ing a file is transmitted as a separate file, appended to 
the file it authenticates e.g-, as part of a file wrapper 
structure, or alternatively, the certificate can be 
25 retrieved from a reference or address e.g. , the URL of the 
certificate on the issuing CA Web Server. 

Transmitting and maintaining digital certificates and 
signed documents as separate files e.g., the digital 
certificate associated to a signed document is stored in the 
30 user's workstation or in a server, presents the advantage of 
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supporting file authentication at any time in a simple and 
well understood way. However^v.if documents are later passed 
on or moved to new recipients ^ associated digital certifi- 
cates can be lost, accidentally removed, or even intention- 
ally removed on the way in an attempt to cheat. 

Wrapping a file with delimiters and appending the 
digital certificate, or the URL of said certificate on the 
issuing CA Web Server, at the end of the signed file is 
convenient, since both the certificate, or the certificate 
address, and the signed content travel together. Conversely, 
the wrapper and the certificate, or the certificate address, 
will typically need to be removed before the file can be 
used. Thus, signature validation only occurs when the 
document is retrieved. If the document is later passed on or 
moved, it may be difficult to check again, since the 
certificate, or the certificate address, could, be lost. 
Furthermore, the method is not compatible with standard file 
formats such as image, video, audio or executable files that 
cannot be recognized prior to authentication. • 
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When a recipient receives an electronic docimientr" if 
the "digital certificate has been appended to\the signed 
document, the recipient must perform the following tasks: 

open the electronic document; 

5 - identify and extract^, from the electronic document, the 

digital certificate 'and the digital signature poirtions 
appended to this electronic document f 

" identify the address and contact the CA to check that 
the appended certificate is a valid certificate, using the 
10 digital certificate content; and^ 

- verify the signature using the public key in the 
certificate. 



It must be observed that if the digital certificate is 
appended to the received electronic document, the recipient 

15 must open the document file for accessing the digital 
certificate required to verify the signature. Even when the 
certificate, instead of being appended, would be refe3renced 
e.g., as a network address or URL, in the received document, 
the address from which the certificate e.g., from a CA Web 

20 Server or directory archive, can foe accessed or retrieved, 
must also be "appended by the sender to the signed document - 
Therefore; it is also required to open the received document 
to get said address needed for accessing the digital 
cer ti f i cat e - 



Thus, there are security problems related to the 
methods described above for verifying the authenticity of 
received or accessed files by the recipient: 

- when certificates are sent as separate files, the 
associated digital certificates could be lost i:^ the 
signed files are later passed on or moved to new 
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recipients. In such case, it is impossible to verify these 
signed files. 

- when certificates^ or certificates addresses, aire 
appended to the signed :files, recipients must open an.d 
process the received files to verify said files. Beforre 
opening a received fiies, parsing the content for 
locating, and retrievitig-, or accessing, the associated 
certificate, there is no way to detenrdns in advance, 
whether the received file has been signed or not i.e. , 
whether it is an "authentdLcated" file or an "impersonated" 
file (a non-signed file) - Likewise, it is impossible to 
determine whether or not -the certificate is valid i.e., if 
it has been issued by a CA, if it has not been revoked., 
and if the certificate date is valid- 
It is also to be noticed that opening files for verifi- 
cation represents an iiuporta-nt security concern. 

Many viruses spread on. the Internet on e-mail attach- 
ments distributed as "impersonated". If a received imperson- 
ated file has been maliciously infected by a virus, opening 
the infected file for the simple purpose of signature 
verification almost surely may "open" the door for infecting 
the receiver's computer. Thi^s is a "security hole" common to 
all signature methods descxibed above, as illustrated by 
operation of the class of public-key algorithms discussed 
herein before. 

Certificates must be issued by certificate, authorities . 
If a certificate becomes compromised, the certificate 
authority can later revoke the certificate, thus rendering- 
invalid all files signed after the signature's revocation 
date. A certificate could become compromised if an 
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unauthorized third-party obtained the private key associated 
with' the certificate. This private key is' typically stored 
on the signer ^5 con^uter. With th*e private key^ an unauthor- 
ized person could essentially forge a signature. If the 
5 recipient receives a file signed with a revoked certificate, 
it is must be discarded as invalid or fake. 

Therefore, before opening a received file, it would be 
advisable to check: 

- if the file has been signed i.e., if it contains a 
10 digital signature and a digital certificate appended or 

referenced; 

- the issuer name i.e., the name of the CA; 

- the name of the user to whom the certificate has been 
issued; and, 

15 - the validity period of the certificate. 

Therefore, there is a need to provide a method and 
systems for accessing a digital certificate from a signed 
file before opening said file, so as to enable the recipient 
of the file to determine if the received file has been 
20 signed i*-'.'e., authenticated, and to check the identify of 
signer e.g-, contacting the signer by e-mail, and the valid- 
ity of the digital certificate before opening said file for 
signature verification. 

Summary of the Invention 

25 Thus, it is a broad object of the invention to remedy 

the shortcomings of the prior art as described here above. 
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It is another object of the irxventioii to provide a 
method and systems adapted for enabling a recipient to check 
whether or not a received file is a signed file, before 
opening said file. 

It is a further object of the izivention to provide a 
method and systems adapted to access t3ie digital certificate 
of a signer, before opening the corresponding files. 

It is still a further object of the invention to 
provide a method and systems adapted for providing the 
identity and address of the signer of a file to the recipi-- 
ent of this file so as to verify signer identity, before 
opening a suspicious file- 

The accomplishiuent of these and other related objects 
is achieved by a method for encoding in the filename of a 
signed file, an address from which th^ certificate required 
to authenticate said signed file can be accessed, said 
method comprising the steps of, 

- encoding said address from wlnich the certificate 
required to authenticate said signed file can be accessed; 

- merging said filename and said encoded address in a new 
filename ; and, 

- renaming said signed file with said new filename, 

wherein said filename and said ejncoded addresses are 
separated by a control character, 

and by a method for authenticatingr a signed file having 
a filename wherein an address from which the certificate 
required to authenticate this signed fi.le can be accessed is 
encoded, said method comprising the stejjs of. 
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- extracting said encoded address; 

" decoding said encoded address; 

- accessing said certificate required to authenticate said 
signed file using said decoded address^ 

5 - authenticating said signed file using said accessed 
certificate . 

Further advantages of the present invention will become 
apparent to the ones skilled in the art upon examination of 
the drawings and detailed description. It is intended that 
10 any additional advantages be incorporated herein. 

Brief Description of the Drawings 



Figure 1 r comprising figures la, lb, and Ic, illustrates 

an example of the algorithm used for encoding, 
in the filename of a file, the address or URL 
wherein the certificate used to signed this file 
is stored. 

Figure 2 , comprising figures 2a and 2b, illustrates an 
example of the algorithm that is used to sign an 
electronic document and of the algorithm that is 
used to chec]c the integrity and to verify the 
signature of a signed file, respectively • 

Figure 3 depicts an example of the environment wherein 
the invention can be implemented. 

Figure 4 shows an example of a signed file content 
wherein the filename is encoded according to the 
invention . 

Figure 5 , comprising figures 5a to 5f, illustrates an 
example of the user's interface when using the 
invention. 
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Detailed Description of the Preferred ESmbodiment 

According to the invention^ the filename of a file that 
is accessed locally or through a computer network is used to 
encode the address ^ or URL, from which the certificate that 
can be used to check the integrity and to verify the signa- 
ture of the file can be accessed- A lexicography is deter- 
mined so as to avoid particular characters that may be 
forbidden by the file system, e.g., "\'* with Microsoft 
Windows system (Windows is a Trademark of Microsoft Corpora- 
tion) , and/or to encode the addresses so as to reduce their 
sizes. Addresses to be encoded may be of any forms e.g., 
local addresses, addresses in private netv^orks or Internet 
addresses, however, for sake of illustratd_on^ the examples 
given in the following description are bas^d on URL type of 
addresses. The address from which the ce^rtificate can be 
accessed can be encoded either when the file is transmitted 
from a server to the user system or when it is locally saved 
or transmitted to another system. 

Figure 1 illustrates an example of thte algorithm used 
to encode a certificate address. As shown on figure la, a 
first step consists in getting the primary filename of the 
file (box 100), i.e. the filename of th^ file, and the 
address or URL of the certificate that is ^required to check 
the integrity and to verify the signatuire of the file, 
referred to as certificate address in the fallowing descrip- 
tion {box 105) . Then, the certificate address is encoded 
(box 110) and merged with the primary filename of the file, 
using particular separators (box 115) before the file is 
renamed with the filename comprising the primary filename 
and the encoded certificate address {box 120 ) . 
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Figure lb depicts an example of the encoding algoritluri 
{box 110) . A variable i is set to zero (box 125) and tlie d'^ 
character is extracted from the certificate address stri.ng 
(box 130) p A test is performed to determine whether the 
5 extracted character is valid or otherwise forbidden by 
filename syntax rules imposed by the file system of tihe 
user's device (box 135). If the extracted character is a 
filename valid character^- variable i is incremented {b^ox 
150) and a test is performed to determine if variable i Iras 

10 reached its maximum value that is^ if all characters of the 
certificate address string have been processed (box 155) , If 
variable i has not reached its maximum value, the last f o ur 
steps of the algorithm are repeated (boxes 130 to 155 ) . 
Else^ if variable i has reached its maximum value^ tlie 

15 process is stopped. If the character extracted from tbe 
certificate address string is forbidden by the filename 
syntax rules ^ a corresponding valid character^ or group of 
characters,, is selected in lexicography table 145 and this 
selected character^ or group of characters, replaces tlie 

20 forbidden one (box 140) , Then variable i is incremented ajid 
the same test described before is performed to determine If 
variable i has reached its maximum value. 

As - an illustration of the algorithm described abov^^ 
consider the case of a file based on Microsoft Word form-at 
25 (Word is a Trademark of Microsoft Corporation) naia^ed 
"Berry-doc", that a user would like to send to someone else 
as an e-mail attachment, using to this purpose a lexicogra- 
phy table to encode the certificate address string into t:iie 
filename, wherein 

30 is associated to 

"/" is associated to " (" 
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To check the integrity and to verify the signatuaire of 
this document- file, it is required to use the certificate 
corresponding to the private key that has been used to sign 
this file. For sake of illustration one can considered that 
this certificate can be downloaded from the following URX: 
http : //www- certauth . com/ certificates /Lewis Carroll . cer 

When the originator of the document "Berry.doc" signs 
the documentr an option such as "Copy path to file" cam be 
selected to encode the URL of the certificate reposiitory 
wherein the certificate required to check the integrity or 
to verify the signature of the document can be accessed. 

The filenarue is modified according to the algoarithm 
illustrated on figure 1. Firstly, by using the pre-^j-ious 
lexicography table^. the certificate repository DUIa is 
encoded as follows : 

littp. . ( (www <certaiitli.com (certificates (Lewis Car roll, cer 

Then, the encoded URL is merged with the filename. In 
this example, the encoded URL is enclosed in parenthesis 
that are used as separators. The encoded URL is inserted in 
front of the extension dot of the primary filename as 
follows : 

Berry (http. * ( Cwww, certauth.com (certificates (Lewis Carroll, cer) .doc 
and the file is renamed using this modified filename. 

It must be noticed that, for sake of illustration, this 
encoding algorithm is purposely very simple. A preferreca one 
would consist in replacing a sequence of forbidden charac- 
ters by a single one e.g*, replacing "//:" by "(»^ Likewise, 
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some sets of characters may be replaced by more compact 
codes e.g.,' replacing "http://" by "H!"- 

Figure Ic depicts an e-mail 160 wherein the filename 
165 of the attached file 170 has been modified to embed the 
5 URL of the certificate address according to the previous 
algorithm- 

When the attachment of the above mentioned e-mail is 
selected to be processed by the receiver, a test is 
performed to determine whether or not the user requests an 
10 integrity check or a signature verification so as to deter- 
mine whether or not the certificate address must be 
extracted from the filename and decoded. 

Using ' the same table of lexicographic transformations 
as the one that has been used by the sender of the file to 

15 encode the certificate address the certificate address or 
URL is extracted and decoded from the filename. To that end, 
certain symbols or groups . of symbols of the ^^encoded URL'^ 
are replaced by symbols or characters that are compatible 
with URL conventions on Internet, as mentioned above, to get 

20 the decoded and valid URL. Using the same example as before, 
the decoded certificate address isr 

http; / /www^certauth , com/certificates /Iiewis Carroll . cer 

Certificates are stored in a database of a certifica- 
tion authority server and, possibly, locally in the certifi- 
25 Gate's owner device- Each certificate comprises at least a 
public key that can be accessed by third parties to check 
the validity or to verify the signature of a signed file. 
The public key of a certificate corresponds to a private key 
that is known only by the certificate ' s owner and by the 



wo 2005/098566 



PCT/EP2005/050925 



15 

certification authority, this private key being used to sign 
files, *aifl^a preferred embodiment, the certificates also 
Goraprise additional information such as the owner's name, 
the certificate? s validity period and the signature 
algorithm as mentioned above. It must be clear that a 
private key is only known by the certificate's owner and by 
the certification authority while all the other information 
relative to the private key and organized as a certificate 
is public and can be accessed by any third party knowing the 
certificate address or URL- 

Figure 2, comprising figures 2a and 2b, illustrates an 
example of the algorithm that is used to sign an electronic 
document and of the algorithm that is used to check the 
integrity and/or to verify the signature of a signed file, 
respectively - 

If the sender has not already a certificate issued by 
certification authority, he/she must apply for the certifi- 
cation authority to issue it. This must be made one time for 
a validity period since a certificate has a validity period. 
Thus, the private key associated to a certificate issued by 
the certification authority can be used by the sender to 
sign all documents during the certificate validity period. 
To get a certificate the sender sends a request to the 
certification authority (step 200) with required information 
such as sender's name. After having assigned a pair of 
private and public keys, the certification authority creates 
a certificate and transmits the private key as well as the 
certificate address to the user having sent the request, 
using a secure connection* The private key and the certifi^ 
cate address are preferably stored locally on the user's 
device however, this information can be stored on a secure 
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server of the certification authority or on personal data 
storage means, such as a smaixt . card . 

After haying selected the file to sign and once having 
received or recovered the required private key and the 
5 associated certificate address (step 210), the user signs 
the file (step 215) • To that purpose, a standard certifica- 
tion algorithm is used to compute a signature based on the 
file to be signed and the private key e.g. Message-Digest-5 
(MD5) with RSA or SHA hashing algorithm with RSA, 

10 In a preferred einbodiinent^ the signature is appended to 

the document as illustrated on figure 4 wherein the signa- 
ture (410) is located at the beginning of the file (400) and 
separated from the content of the document (405) by tags 
"BEGIN SIGNATURE" and "END SIGNATURE". Then, the address or 

15 URL of the server wherein the public key that is required to 
check the integrity or to verify the signature of the file 
is encoded in the filename (step 220) as described by refer- 
ence to figure 1. As mentioned above^ the address or URL 
wherein this public key is stored is preferably provided by 

20 the certification authority when issuing the certificate 
however, it can be transmitted to the senderir upon request, 
each time he/she signs a document. Therefore, at the end of 
the algorithm depicted on figure 2a, the resulting file is 
signed and contains a link to a server wherein a certificate 

25 may be recovered to check the integrity of the resulting 
file or to verify the embedded signature. 

Figure 2b illustrates an example of the algorithm that 
can be used to check the integrity or to verify the signa- 
ture of a signed file encoded according to the invention. 
30 The first step consists in decoding the filename of the 
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filer as described above, to retrieve the address or URL 
wherei"n the certificate that is required to check the integ- 
rity or to verify the signature is stored (step 225) . Then, 
using this decoded address or URL, the user can access the 
certificate from a server, preferably controlled by a certi- 
fication authority (steps 230 and 235), without opening the 
file. At this stage, the user can access information related 
to the certificate, such as the name of the person to whom 
the certificate has been delivered, the validity period of 
the certificate and the signature algorithm. Therefore, the 
user is able to check the certificate to determine whether 
or not the owner of the certificate is the one he/she 
expects to be (steps 240 and 245) . Then, using the public 
key of the certificate, it is possible to authenticate the 
file i.e., to check the integrity of the file and/or to 
verify the signature (steps 250 and 255), by using a 
standard authentication algorithm. As suggested by dotted 
lines, the user can authenticate the signed file without 
checking the certificate. Naturally the certificate can 
contain information relative to the authentication algorithm 
that could be used, or must be used, depending upon the 
certification authority policy. Still in a preferred eaibodi- 
ment, the certification authority can provide the user means 
to download an authentication applet when hs/she accesses 
the certificate so as to check the integrity and verify the 
signature of the file. 



Figure 3 depicts an example of the environment wherein 
the invention can be mplemented. For sake of illustration 
the main steps of the algorithms described on figures 2a and 
2b are illustrated with referenced arrows. As described 
above, a user (300) who has no certificate and who wants to 
sign a file must access a certification authority server 



wo 2005/098566 



PCTyEP2005/05092S 



18 

(310) through a network (305) e.g., Internet. Certificates 
generated by the certiification authority (320) axe locally 
storedL in a certificate database (315) of the certification 
authoirity server (310) . Likewise, when a user (325) having a 
signed, file e.g., received as an e-mail attachment, wants to 
check its integrity and to verify the signature, he/she 
accesses through a network (305) the public key of the 
certificate which address or URL is encoded in the filename 
of the signed file to check. 

Figure 4 shows a signed file (400) comprising the 
document (405) and a signature (410) that can be used to 
check the file integrity and to verify the identity of the 
document's author. The address or URL of the certification 
authority server wherein the certificate corresponding to 
the private key used to sign the file is encoded and stored 
in the filename (415) . 

Figure 5, comprising figures 5a to 5f, illustrates an 
example of the user^s interface when using the invention.. 
Figures 5a to 5d depict an example of certificate panel 
while figures 5e and 5f show how a certificate address or 
URL can be linked to a file- 

rhe certificate panel illustrated on figures 5a to 5d 
comprises 4 tabs depicted on each of these figures, respec- 
tively, these tabs comprising information relative to: 

- general tab: 

• owner of the certificate, 

certification authority having delivered the 
certificate, and, 

* validity period. 
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- detail tab: 

"'7--. • version identifying the certificate; format^ 

• serial number (unique within the certification 
authiority) , 

• signature algorithm (identifying the issuer»s hash 
aigorithia and digital signature algorithm used to sign the 
certificate) , 

• issuer name (the name of the certification 
auth-ority) , 

• the beginning of the validity period^ 

• the end of the validity period, 

- - subject name (the name of the user to whom the 
certificate is issued) r 

• subject public key field (including Algorithm 
name and the Public Key of the subject), 

• extensions, and, 

• signature of the certification authority, 

- certification path {address or URL of the certificate 
on the certification authority server) , and, 

- download SW (comprises links software applications or 
applets that are adapted, for example, to check the valid- 
ity of a file or to verify a signature) . 

Most of these fields are completed by the certification 
authority after having received a request for a certificate 
and an identifier or subject name. The private and public 
keys arre computed according to standard algorithms. 

Figures 5e and 5f depict an example of the interface 
that can be used to encode a certificate address or URL into 
the filename of a file. After having selected a file in the 
file manager, the user can click on the right button of the 
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mouse to display a pop-up menu comprising a "Paste path to 
file" option. Thenv.-the path previously raeraorized in the 
clipboard or selected by other means is encoded in the 
filename of the file according to the method described by 
5 reference to figure 1. 



Naturally, in order to satisfy local and specific 
requirements^ a person skilled in the art may apply to the 
solution des.cribed above many modifications and alterations 
all of which^ however, are included within the scope of 
10 protection of the invention as defined by ' the following 
claims . 
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ClaiEis: 



1. A method for encoding In the filename of a signed file, 
an address from which the certificate required to authenti- 
cate said signed file can be accessed, said method compris- 
ing the steps of, 

- encoding said address from which the certificate 
required to authenticate said signed file can be accessed 
{step 110); 

- merging said filename and said encoded address in a new 
filename (step 115) / and, 

- renaming said signed file with said new filename (step 

120), 

wherein said filename and said encoded addresses are 
separated by a control character. 

2. The method of claim 1 wherein said step of encoding the 
address from which the certificate required to authenticate 
said signed file can be accessed comprises the steps of : 

- • analyzing the address from which the certificate 
required to authenticate said signed file can be accessed 
to detect predetermined characters (step 135); and, 

- replacing said predetermined characters by associated 
characters (step 140), 

said predetermined and associated characters being stored 
in a lexicograpliy table (145) . 



3. The method of either claim 1 or claim 2 wherein the 
encoded address is merged with said filename, by inserting 
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the encoded address in front of the extension dot of said 
filename. . 

4. The method of any one of claims 1 to 3 further compris- 
ing a compression step to reduce the size of the encoded 
address. 

5. A method for authenticating a signed file having a 
filename wherein an address from which the certificate 
required to authenticate this signed file can be accessed is 
encoded, said method comprising the steps of , 

- extracting said encoded address; 

- decoding said encoded address {step 225) ; 

- accessing said certificate required to authenticate said 
signed file using said decoded address {steps 230 and 
235), 

- authenticating said signed file using said accessed 
certificate (steps 240 to 255) . 

6. The method of claim 5 further comprising the step of 
checking said certificate before authenticating said signed 
file- 

7. The method of either claim 5 or claim 6 wherein said 
step of accessing said certificate required to authenticate 
said signed file further comprises the step of, 

- downloading an authentication function according to 
information contained in said certificate. 
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8. The method of any one of claims 5 to 7 wherein said 
step of a-uthenticating said signed {file comprises at least 
one of the steps consisting in checking the integrity of 
said signed file and in verifying the signature, 

5 9. The method of any one of claims 5 to 8 further compris- 
ing the step of extracting a public key from said certifi- 
cate,, said public key being used to authenticate said signed 
file. 

10, The method of any one of claims 1 to 9 wherein said 
0 certificate is stored in a server of an authentication 
authority. 

11- An apparatus comprising means adapted for carrying out 
each step of the method according to any one of the claims i 
to 10. 



12. A computer-like readable medium comprising instructions 
for carrying out each step of the method according to any 
one of the claims 1 to 10, 
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L Carron@rBM.COM 
31/03/2004 



To: Jfriday65@yahoo.com 
Dc: cc: 

Subjecfc^ubject; Le tiuo de Berry 



John, 

The Tr^s riches heures du due de Berry" is usually referred to 
as "iB roi des manuscrits enlumin^s" or "the king of the 
Itiumlnated mariu scripted, but it is also a pinnacle In the entire 
history of painting. 

Commissioned by Jean, due de Berry In 1413, it was painted by 
the Umbouig brothers who left it unfinished at their (and the 
due's) death un 1416. The due Charles I de Savoie 
commissioned Jean Colombe to octfnplate the painfing of the 
manuscript between 1485-1489. 

See attached a signed copy of the draft of my doctoral thesis 
iifom my research on this subject. 
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END SIGNATURE- 



litms Carroll, ^oni3Be«land rasfict^muL 

405 

WHAT IS IHB TJRES RICHES BETOUES? 

The Txes Riches Heures is ths classic escample of amedieval book of hours. This was a 
collectioa of fhe text fbr each liturgical hour of the day - hsDCQ the same - wMck o&ea 
included other^ supplementaiy; texts. Calendais, p^sy&s^ psalzns and masses fbr cerlaxDi 
Iioly days were coniraoiily included. 

The ;>ictaies intMs directoiy are fiom the caleiidaf section of the Tres Riches Heures. 
This was painted some time between 1412aad 141 6 and is arguably ihe most "beautiM 
pait<Kf Ihe manuscript; it is cejrtaijjly the best fcnowo, bexxig oae of the ^reat art treasxnres 
of Fxance. latemis of Mstcsdcal and cultural hnportance:^ it is c^tainly equal to mss^ 
tamm wodEB sudi as the MbnaLisaj marlriTig the piimacle of fte 9£t of ooaiLiiscript 

WHO PA1NX3EI>TTO lEES ISHCBES HEtlRES? 

The Trefi Kichsfi Heures was painted by fhs Limbotw^ hrotihexs, Paud^ Hermann and Jeaa. 
They came from TCmwegen in what is nowHanders but were generally refeired to as 
QemmsYaxy IMeis known aboiit them; they m believed to hav& been bom in the lata 
137DS or iSSQs and were bom into an artistic firaily, thear fititftrbeing a wood sculptor 
£aidifaeir uncle beh]gaoDiBr&tworkh)gva^usly£ur the PiendLQaeenandfortheDuc de 
Bourgogne. 

They seem fo have followed m their tiacslefs footsteps and by 1402 had entered into the 
service of the Duo de BomBogae as artists. 3y 14(18 they bad entstedthe service of Jean, 
Doc de Benay, one of the most notable (cmdnchestl) art Lovens mFiance. They are knovm 
to have exeonfBd several other pieces of wodc apait jSrom the Ties "Biichts Heuxes bi^ most 
, X. 
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